Date: Sun, 10 Apr 94 04:30:13 PDT
From: Ham-Digital Mailing List and Newsgroup <ham-digital@ucsd.edu>
Errors-To: Ham-Digital-Errors@UCSD.Edu
Reply-To: Ham-Digital@UCSD.Edu
Precedence: Bulk
Subject: Ham-Digital Digest V94 #107
To: Ham-Digital


Ham-Digital Digest          Sun, 10 Apr 94       Volume 94 : Issue  107

Today's Topics:
                     Ham-Digital Digest V94 #102
                           JNOS vs. WNOS ??
                        sexually explicit talk
                                 TAPR
                           TAPR File server

Send Replies or notes for publication to: <Ham-Digital@UCSD.Edu>
Send subscription requests to: <Ham-Digital-REQUEST@UCSD.Edu>
Problems you can't solve otherwise to brian@ucsd.edu.

Archives of past issues of the Ham-Digital Digest are available 
(by FTP only) from UCSD.Edu in directory "mailarchives/ham-digital".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: 7 Apr 94 18:38:24 GMT
From: news-mail-gateway@ucsd.edu
Subject: Ham-Digital Digest V94 #102
To: ham-digital@ucsd.edu

Your message was received at 04/08/94  5:25pm
 
  ----- The following address had delivery problems -----
STROHS  (User does not exist)
 
From: Ham-Digital Mailing List and Newsgroup <ham-digital@UCSD.EDU>
Subject: Ham-Digital Digest V94 #102
Date: Fri,  8 Apr 94 02:38:24 PDT
To: To: strohs@strohpub.com
Message-Id: <199404080938.CAA05222@ucsd.edu>
 

------------------------------

Date: 9 Apr 94 16:07:44 GMT
From: agate!howland.reston.ans.net!pipex!demon!dakevar.demon.co.uk!duncan@ucbvax.berkeley.edu
Subject: JNOS vs. WNOS ??
To: ham-digital@ucsd.edu

In article <764557213.AA00617@afarm.uucp> Ted.Cross@f40.n382.z1.fidonet.org writes:

>Organization: MicroLithics Corp.
>
>
>Hi there es tnx fer reading this.
>
>I've been a user of WNOS for some time and NOS before that. I've noticed
>references to JNOS. I've had a quick look around one or two sites but
>not found much info on JNOS. Has anyone out there got any insight into
>the differences between WNOS and JNOS and which is better, I assume JNOS
>is the new kid on the block and potentially the next generation!!

Ted,

We've been using WNOS4 for some time at GB7SIG and had no problems until 
we had a sudden increase in user activity.   When the mail activity got 
large WNOS could not cope.  We tried the beta version of WNOS5 but this 
seems to suffer from the same problem.

We are now trying to set up JNOS but are having lots!!! of trouble.  Short
answer is, if its for your own BBS then WNOS4 is great.  JNOS needs more work
to get the setup right.  I have JNOS working at home but there seems to be
a problem with memory.  The mailer does not work at present, probably because
of the lack of memory so watch this space.

I look forward to your comments and perhaps info from other areas.

Best regards & 73's


Duncan R Goodacre  G7EXG

------------------------------

Date: 9 Apr 1994 04:31:12 GMT
From: ihnp4.ucsd.edu!library.ucla.edu!europa.eng.gtefsd.com!news.umbc.edu!eff!news.kei.com!yeshua.marcam.com!insosf1.infonet.net!usenet@network.ucsd.edu
Subject: sexually explicit talk
To: ham-digital@ucsd.edu

In article <765776764snx@skyld.grendel.com>, jangus@skyld.grendel.com (Jeffrey D. Angus) writes:
>I found this over on rec.radio.amateur.packet. THought someone might wish to
>give him a hand.
>
>In article <Cns42x.2Bu@iat.holonet.net> bgould@iat.holonet.net writes:
>
>  > 
>  > Dear anyone,
>  > I don't have a liscense, but I bought a ham radio recently and was thining
>  > about opening sexually explicit gay chatline through info packets over the
>  > air. Is  there any way the government could monitor these conversations,
>  > as some of them could possibly involve underage men. If anyone is
>  > inerested in subscribing to my packet service, feel free to contact me or
>  > DeanSf@aol.com.
>  > 
>  > Thanx, 
>  > 
>  > bgould@holonet.net
>  > 
>  > 
> Amateur: WA6FWI@WA6FWI.#SOCA.CA.USA.NOAM | "You have a flair for adding
>Internet: jangus@skyld.grendel.com        |  a fanciful dimension to any
> US Mail: PO Box 4425 Carson, CA 90749    |  story."
>   Phone: 1 (310) 324-6080                |           Peking Noodle Co.
>
Hey! April 1st has passed us by!
73, Bill; W0OMV
ax25: w0omv@wr9b.#wcil.il.usa.noam
tcpip: w0omv.ampr.org [44.50.32.5]
Internet: billh@ins.infonet.net

------------------------------

Date: Sat, 9 Apr 1994 15:04:34 GMT
From: ihnp4.ucsd.edu!agate!howland.reston.ans.net!newsserver.jvnc.net!yale.edu!noc.near.net!das-news.harvard.edu!cantaloupe.srv.cs.cmu.edu!news@network.ucsd.edu
Subject: TAPR
To: ham-digital@ucsd.edu

The previosuly posted instructions for accessing TAPR's list server
are incorrect. The proper address is "file-request@tapr.org". Don't
send file requests to tapr@tapr.org!

		Mike Blackwell  --  ke3ig  --  mkb@cs.cmu.edu

------------------------------

Date: 9 Apr 94 18:29:49 GMT
From: news-mail-gateway@ucsd.edu
Subject: TAPR File server
To: ham-digital@ucsd.edu

It looks like I goofed in a message I sent out the other day.  The file
server at TAPR can be reached at the address file-request@tapr.org.  To 
get the help file and a list of available files, send a message to

file-request@tapr.org

In the body of the message, type the lines:

help
dir
quit

The information will be sent to you.  A reply-to line in your header will 
help in cases where the return information is hard to decipher.

The address given previously, tapr@tapr.org goes to a human who will be
glad to take your orders or process membership applications, etc., but 
cannot send you the requested files.  This can only be done by the 
file robot.

------------------
Bob Nielsen, W6SWE              Internet: w6swe@tapr.org
Tucson, AZ                      Amateur IP: 44.124.12.16
                                ax.25: w6swe@wb7tls.az.usa.na

------------------------------

Date: 8 Apr 1994 21:04:56 GMT
From: news.mentorg.com!hpbab33.mentorg.com!wv.mentorg.com!hanko@uunet.uu.net
To: ham-digital@ucsd.edu

References <Cnr9x1.II6@world.std.com>, <2nuqbe$omj@hpbab.mentorg.com>, <2nvfu0$1ve@ccnet.ccnet.com>
Reply-To : Hank_Oredson@mentorg.com
Subject : Re: NTS traffic on packet

In article <2nvfu0$1ve@ccnet.ccnet.com>, rwilkins@ccnet.com (Bob Wilkins  n6fri) writes:
|> Hank Oredson (hanko@wv.mentorg.com) wrote:
|> 
|> : What would prevent duplicates or lost messages?
|> : How would you accomplish this?  Remember we don't have a "fixed
|> : configuration" network.  We don't have reliable paths.  We do have multiple
|> 
|> I don't understand. There are fixed routes in and out of any full service bbs.

Now I'm confused.  How are these routes fixed?  What happens when a
forwarding partner goes off air?  What happens when a node goes down?
How are backup routes handled?  I see "fixed routes" on a hour to hour
basis, but not on a year to year basis. Often, not even on a week to week basis.

|> The HF routes may seasonally change and require manual assistence. 
|> What is going to happen if the BBS protocol is allowed to be the rule on 
|> the DASH digital amateur super highway. It is my understanding that the 
|> proposal for the 219 MHz 56kb DASH will require point to point auxiliary 
|> operation. Will the bbs protocol work in this new arena?

Well ... the bbs authors don't care much - this is just data transport.
Bytes get from point A to pont B, not important how they get there.
i.e. it has nothing to do with the bbs protocol.

|> Maybe the answer is to make the 219 MHz DASH a tcp/ip network and put the 
|> bbs mail traffic into <envelopes> for safe transport across the network. I 
|> would like to see some more discussion on the future implementation of 
|> this new network. 

That is what we already do, but with other protocols: AX.25, NET/ROM,
CLOVER, AMTOR, PACTOR, whatever. tcp/ip as tranport protocol has not made
much inroad in the bbs network, for various reasons. It really does not
matter what transport protocol is used, the bbs system does not care.

|> Has anyone done any traffic analysis of bbs messages? Are the bulk of the 
|> messages two or three hops? With the increase in network speed will the 
|> message flow naturally increase? Will my bbs mail reading program be able 
|> to keep up with the vast number of bulletins that will be arriving? I 
|> realize that I will be reading at 1200 for quite some time ... maybe 9600 
|> if the bbs operators will provide this service. 

Yes, much traffic analysis.  The bulk of message traffic is "many hop".
At each increase in network capability to date, traffic has increased to
saturate the new capability within a short time. I already have users at
9600 baud, and they are asking for faster response ...

At least in the PNW, traffic has been running roughly equal volume (in
bytes) between personal and bulletins, with twice as many personal messages
as bulletins flowing through the system.        

One thing to think about though: we have two different services represented
by the existing bbs network. There are single sender to single recipient
messages (e.g. personal messages) and also single sender to multiple
recipient messages (e.g. bulletins). We now tend to handle these messages
types a little differently - mostly by giving some priority to the personal
messages. Whatever transport mechanism we use will make little difference
to the day to day operation of a bbs system though - the messages will come
in, they will go out, users will send and read them.

|> Sorry Hank, I am not a network guru, just your average packet user. 
|> 
|> Bob
|> 
|> 
|> : -- 
|> 
|> : Hank Oredson @ Mentor Graphics
|> : Internet     : hank_oredson@mentorg.com
|> : Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM
|> 
|> 
|> 
|> -- 
|>      Bob Wilkins                     work    bwilkins@cave.org
|>  Berkeley, California                home    rwilkins@ccnet.com
|>      94701-0710                      play    n6fri@n6eeg.#nocal.ca.usa.noam

-- 

Hank Oredson @ Mentor Graphics
Internet     : hank_oredson@mentorg.com
Amateur Radio: W0RLI@W0RLI.OR.USA.NOAM

------------------------------

Date: Fri, 8 Apr 1994 18:53:46 GMT
From: elroy.jpl.nasa.gov!swrinde!gatech!howland.reston.ans.net!pipex!sunic!psinntp!psinntp!arrl.org!jbloom@ames.arpa
To: ham-digital@ucsd.edu

References <01HATOE2L7VM91WF9U@stthomas.edu>, <1994Apr6.214215.2580@arrl.org>, <williams.765739386@maui>et
Subject : Re: GTOR INFO

Paul Williamson (williams@maui.qualcomm.com) wrote:
: jbloom@arrl.org (Jon Bloom (KE3Z)) writes:
: >This is true.  it might have been better had G-TOR stuck to a 200-baud
: >upper limit.  We have enough wide-bandwidth signals on the bands now.

: At least G-TOR only upshifts to 300-baud when it has enough data to
: justify it.  It doesn't take up the wider bandwidth unless it needs to.
: I don't see anything wrong with taking up bandwidth as long as you're
: not wasting it.

Well, there are two problems.  The first is that many radios have as
their available filter selections 2.1 kHz (or so) and 500 Hz. A
300-baud, 200-Hz-shift signal really needs a wider filter than 500 Hz.
So 300-baud operators (like existing HF packet ops) tend to use their
SSB filters. Then they can't tolerate interference on adjacent channels
because the interfering signals fall within their filter passbands, so
they space out to 2-kHz separation.  In this case, these stations *are*
effectively taking up bandwidth that they aren't really using.

The second problem is that in an environment in which signals are not
subbanded (if that's a word) by transmission mode, the use of signals
of different widths make sharing the spectrum more difficult.
-- 
Jon Bloom KE3Z   jbloom@arrl.org

------------------------------

End of Ham-Digital Digest V94 #107
******************************
